Re: chroot'ed environment?
der Mouse (mouse@Collatz.McRCIM.McGill.EDU)
Wed, 19 Apr 1995 17:47:13 -0400
>> Also, if it is not too off-topic, what would be the best way to
>> allow syslogs after a chroot, if the syslog daemon uses unix
>> datagram sockets, that dont survive the chroot call?
> There are several approaches that have been used; all have their
> limitations. You could change the syslog subroutine to use the UDP
> port. You could use a UNIX stream socket. Or there's a hack that
> works on some systems, if you need only one chroot'ed syslogd...
> Make /dev/syslog a symlink to the real location of the socket,
> perhaps /usr/ftp/dev/syslog. Fire up syslogd with the (often
> undocumented) -p option, telling it the real location.
If I might offer the solution I use for my ftpd....
Hardlink /dev/log to /ftp/dev/log. You need to do this each time
/dev/log is recreated, of course. It depends, of course, on the ftp
chroot() area being on the same filesystem as /dev/log.
If all your chroot areas are on the same filesystem, but different from
/dev, you may be able to combine these two ideas: make all the chroot
/dev/logs hardlinks to one another, and symlink the non-chroot /dev/log
to some one of them.
An idea which just occurred to me, not tested at all. If you can
connect() an AF_UNIX SOCK_DGRAM socket (and I'm not sure you can), the
association with its peer might survive a chroot that renders the
original pathname inaccessible. If this is so, it could provide an
answer.
And, of course, you could always write a stupid little daemon that does
recv()s on /ftp/dev/log and turns around and sendto()s the packets to
the real /dev/log.
der Mouse
mouse@collatz.mcrcim.mcgill.edu